REMARKS 

In the Office Action, the Examiner rejected Claims 1-19, which were all of the then 
pending claims, under 35 U.S.C. §§101, 102 and 112. The claims were rejected under 35 U.S.C. 
§101 as being directed to non-statutory subject matter, were rejected under 35 U.S.C. §102 as 
being fully anticipated by U.S. patent application publication no. 2004/0181753 (Michaelides), 
and were rejected under 35 U.S.C. §1 12 as being indefinite. 

All of these rejections are respectfully traversed for the reasons set forth below. 
Independent Claims 1, 7 and 13 are being amended to emphasize differences between the claims 
and the prior art. Also, new Claim 20, which is dependent from Claim 19, is being added to 
describe expressly details of the preferred embodiment of the invention. 

For the reasons discussed below in detail, Claims 1-20 are directed to statutory subject 
matter, are clear and definite, and patentably distinguish over the prior art and are allowable. 
The Examiner is thus respectfully asked to reconsider and to withdraw the rejections of Claims 
1-19 under 35 U.S.C. §§101, 102 and 112, and to allow Claims 1-20. 

Each of the rejections of the claims under 35 U.S.C. §§101, 102 and 1 12 is discussed 

below. 

35 U.S.C. §101 

In rejecting the claims under 35 U.S.C. §101, the Examiner argued that the claimed 
invention merely comprises functional material and does not represent any actual real world 
application to produce a concrete tangible and useful result. 

Applicants respectfully disagree. 

Applicants have considerable discretion as to how to define the invention. In the present 
case, the independent Claims 1, 7 and 13 describe elements - first, second and third components 
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-that are used in the invention and describe the functions that these elements perform in the 
operation of the invention. The first component is used for reading data, the second component 
is used for processing the data, and the third component is used for loading the data into a data 
destination. 

This language does not describe a mere intent or a mere result, but instead describes the 
actual functions performed by the components. These functions - reading, processing and 
loading data - are concrete, tangible and useful, and also are practical, real world applications. 
Accordingly, the independent Claims 1, 7 and 13, and the dependent Claims 2-6, 8-12 and 14-19, 
are directed to statutory subject matter within the meaning of 35 U.S.C. §101, and the Examine is 
respectfully asked to reconsider and to withdraw the rejection of Claims 1-19 under 35 U.S.C. 
§101. 

35 U.S.C. §112 

In the Office Action, the Examiner argued that the claims recited using components 
without any active, "positive operation delimiting how these using components are actually 
practiced," and, on this basis, the Examiner rejected Claims 1-19 under 35 U.S.C. §1 12. The 
Examiner also objected to the phrase "can be modified," arguing that it is uncertain whether the 
recited limitation actually did happen. 

Applicants respectfully submit that the claim language is not indefinite or unclear. 

With respect to the description of the components and how they are used, the claim 
language, as discussed above, describes in a positive, clear manner the way in which the 
components are used to achieve the claimed results. Generally, the first component is used for 
reading data, the second component is used for processing the data, and the third component is 
used for loading the data into a data destination. These are all positive operations describing 
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how these components are actually used. The elements of the claims are described in terms of 
the functions these elements perform, which is an acceptable way to define the invention. 

The description in Claims 1, 7 and 13 that each of the components can be modified, also 
is a positive limitation describing an actual feature of these components. As described in the 
claims, an important aspect of the invention is that each of these components has the ability to be 
modified, adjusted and replaced independently of the other components. This too is a positive, 
clear and definite limitation that describes actual features of the claimed elements. 

Applicants' Attorneys have carefully reviewed all of Claims 1-20, as presented herewith, 
and these claims are clear and definite and fully comply with the requirements of 35 U.S.C. 
§ 1 12. The Examiner is thus also respectfully requested to reconsider and to withdraw the 
rejection of Claims 1-19 under 35 U.S.C. §1 12. 
35 U.S.C. §102 

This independent nature of the above-discussed components is an important aspect of the 
present invention that is not shown in or suggested by the prior art. This feature of the invention 
is discussed in paragraphs 1 9-23 of the application. There, it is explained that each of the 
components 16, 20, 22, 24 and 26 operates independently of the other of the components, so that 
each component can be modified or replaced without affecting the operation of the other 
components. Also, as discussed in paragraphs 19-23 of the specification, this independent 
operation means that the individual components 16, 20, 22, 24 and 26 can be updated or 
modified by authorized administrators during use of the framework 10. Specific examples of a 
file or code that can be used with or in framework 1 0 are shown in Figures 3-6. 

To elaborate, the present invention relates to mapping data from a source to a destination, 
and in particular, to doing this in a way that makes it easy to work with different types of data 
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sources. This is done by providing a framework, or system, having a group of components, each 
of which can be readily modified or replaced independent of the other components, for handling 
various functions as data is mapped from the source to the destination. More specifically, the 
first components is used for reading the data from the source, and the second of the components 
is used for receiving the data from the first of the components and for processing the read data 
according to a set of rules. The third component is used for receiving the data from the second of 
the components and for loading the data into the data destination. 

Mapping data in this way allows, for example, one application to be accessed by different 
users in different parts of the world even though those users might use different formats for 
dates, time and money, or for other reasons. Also, the present invention can map data in 
different formats into a single, common database by simply changing or replacing the 
appropriate component of the mapping process used with a particular individual. 

Michaelides describes a software tool for converting a source format to a target format. 
As shown in Figure 6 of Michaelides, this software tool is comprised of a series of functional 
blocks, including a transformation engine, a formatting engine, a user interface, a feed database 
and a rule database. These functional blocks, however, do not operate in an independent manner, 
as the components of the present invention do. For instance, the functional blocks of 
Michaelides use rules from other functional blocks to process the data. Thus, a change in one 
functional block may have a direct affect on the specific way another functional block operate. 

Independent Claims 1, 7 and 13 describe the above-discussed aspect of the present 
invention. In particular, each of these claims describes a plurality of separate components, 
operating in series, for performing defined functions to map the data from the source to the 
destination. A first of these components is used for reading the data from the source, and a 
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second of the components is used for receiving the data from the first of the components and for 
processing the read data according to a set of rules. A third of the components is used for 
receiving the data from the second of the components and for loading the data into the data 
destination. Each of the components operates independently of the other of the components, and 
each of the components can he modified, adjusted and replaced independent of the other of the 
components to facilitate mapping data from a plurality of different types of data sources having 
data in different types of formats into the data destination. 

The other references of record haveheen reviewed, and these other references, whether 
considered individually or in comhination, also do not disclose or suggest this feature of the 
present invention. 

In light of the above-discussed differences between Claims 1, 7 and 13 and the prior art, 
and because of the advantages associated with those differences, it cannot be said that any of 
these claims is anticipated by or is obvious in view of the prior art. Accordingly, these Claims 1 , 
7 and 13 patentably distinguish over the prior art and are allowable. 

Claims 2-6, 19 and 20 are dependent from, and are allowable with, Claim 1. Likewise, 
Claims 8-12 are dependent from Claim 7 and are allowable therewith; and Claims 14-18 are 
dependent from, and are allowable with, Claim 13. The Examiner is, accordingly, respectfully 
requested to reconsider and to withdraw the rejection of Claims 1-19 under 35 U.S.C. 102, and to 
allow these claims and Claim 19. 
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For the reasons discussed above, the Examiner is asked to reconsider and to withdraw the 
rejection of Claims 1-19 under 35 U.S.C. §§101, 102 and 112, and to allow Claims 1-20. If the 
Examiner believes that a telephone conference with Applicants' Attorneys would be 
advantageous to the disposition of this case, the Examiner is requested to telephone the 
undersigned. 



Scully, Scott, Murphy & Presser, P.C. 
400 Garden City Plaza, Suite 300 
Garden City, New York 1 1 530 
(516)742-4343 

JSS:Jy/dg 



Respectfully submitted, 




/John S. Sensny 
Registration No. 28,757 
Attorney for Applicant 
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